home *** CD-ROM | disk | FTP | other *** search
/ Inter.Net 55-2 / Inter.Net 55-2.iso / linux / speciale / bakasub / ati.txt next >
Text File  |  2000-01-21  |  19KB  |  412 lines
  1.                                 BakaSub/Linux
  2.                                 Version 0.1.1
  3.                           Copyright (C)1998 Dan Potter
  4.                             http://bard.home.ml.org/
  5.  
  6. This file contains supplementary info on using an ATI All-in-Wonder or
  7. All-in-Wonder PRO under Linux for subtitling. You can't do a whole lot
  8. else useful with it but it does do some neat tricks. I am, e.g., watching
  9. The Wall in the background of the Pico session while typing this. Pretty
  10. trippy...
  11.  
  12. I recommend you read this all the way through and understand what I'm
  13. talking about BEFORE STARTING. You may notice something I've left out that
  14. you'll need. No, I didn't leave anything out on purpose (as that kinda
  15. sounds =), but I may have left something out on accident. Better to know
  16. now than when you've got a trippy half-working display of The Wall running
  17. through your screen.. hehe =)
  18.  
  19. This file is valid for the ATI All-in-Wonder and PRO *PCI* cards, although
  20. it may work with AGP. I dunno.
  21.  
  22.  
  23. Background
  24. ----------
  25. So... you seek the spell of GENLOCK?? ;-)
  26.  
  27. Well, TOO BAD cause ATI DOESN'T LOVE YOU like their WINDOWS USERS!!
  28.  
  29. But that's alright. That's what hackers are for.
  30.  
  31. I am currently working on an evil work-around to get a basic 640x480
  32. genlock working in Linux using the ATI All-in-Wonder and All-in-Wonder Pro
  33. cards. I have the former.. quality ain't too good but it's a lot better
  34. than nothing =). The genlock itself is actually about as good as you can
  35. expect to get in Windows, and there are a few caveats that go with it.
  36.  
  37. There are two major components to this little hack:
  38.  
  39. - video input
  40. - video output
  41.  
  42. The first is, paradoxically, much easier to obtain. The current workaround
  43. I have involves using DOSEMU to run their M64DIAG program, and then
  44. switching to X (which is already running in 640x480). The result is a nice 
  45. chromakeyed video input taking up the whole screen. Definitely not perfect
  46. but not too bad either.
  47.  
  48. Their tech support told me that setting up the video input is VERY HARD
  49. (as if we couldn't do it) but the above suggests that the video overlay
  50. almost sets itself up. Because you can switch modes in X and the TV input
  51. window stays there, same size. Which ought to tell you once again how much
  52. they love us.
  53.  
  54. The second problem, again pardoxically, is much harder. The reason is that
  55. the TV output is _very_ picky about its mode timings. I say paradoxically
  56. because it's very easy to get the TV output to turn on in Linux. You can
  57. just hook up your TV and then boot Linux... works great. You can also go
  58. into DOSEMU and use "install tvon" from the M64 diags, and that works
  59. fine. HOWEVER, switching video modes manually (without using the ATI BIOS)
  60. causes the TV output and the standard video output to both go crazy. I'm
  61. not sure if there's an easy workaround for this one unfortunately. I tried
  62. capturing the SVGA regs during the M64DIAG program and constructing X mode
  63. timings from it, but something's still not right.
  64.  
  65. I did have a thought that may solve both of these problems but would
  66. require a GREAT DEAL of effort. Well, if you're a die-hard, you'll do it,
  67. right? ;-)
  68.  
  69. You need a Linux 2.1.12x kernel with "vesa framebuffer console" turned on,
  70. and the XFree86 framebuffer server. What you're gonna do is basically the
  71. same as the above, except you'll set Linux to use 640x480x24 (or whatever)
  72. on Linux startup, then let ATI do the same for you under DOSEMU. Now you
  73. can switch consoles, no problem, and you're in the same video mode.
  74.  
  75. Maybe ATI will get smart and release their specs eventually but I kinda
  76. doubt it. My guess is that this will go like all other people reluctant to
  77. release hardware specs eventually -- people will get sick of not having
  78. the features they paid for, will hack it out WITHOUT ATI's help, and their
  79. card will look bad... at that point they have nothing to lose so they
  80. help. I hope so anyway =)
  81.  
  82.  
  83. Down and dirty
  84. --------------
  85. Ok, no matter how you get things rolling, you're gonna need one thing for
  86. sure -- a working DOSEMU setup that can access your video card's BIOS
  87. and PCI address space.
  88.  
  89. I'm using RedHat 5.2, which comes (handily) with DOSEMU 0.98.1. I highly
  90. recommend that you obtain this version to work with, as it reduces the
  91. number of variables and makes sure everything is up to date enough to work
  92. with your card.
  93.  
  94. Ok, to start off, let DOSEMU and friends get at your video card. Look in
  95. the file /proc/pci for your video card. You should see "VGA compatible
  96. controller" and then a chip designation. A few lines down will be a line
  97. that says something like "I/O at 0xe400 [0xe401]". The first number
  98. (0xe400) is the one to note. That is what mine says, so I will use it as
  99. an example from here out. Note that if you change motherboards or move
  100. your PCI cards around, this number may change.
  101.  
  102. Now edit your /etc/dosemu.conf file and turn on the video stuff. You can
  103. probably figure out the equivalent lines in your version of DOSEMU (if not
  104. 0.98.1) but here is what it is for that version. Change these lines:
  105.  
  106. $_video = "vga"
  107. $_console = (1)
  108. $_graphics = (1)
  109. $_videoportaccess = (1)
  110. $_vbios_seg = (0xc000)
  111. $_vbios_size = (0x10000)
  112. $_vmemsize = (1024)
  113. $_chipset = "plainvga"
  114.  
  115. Ok, that's a good start. Now you need to give DOSEMU a bunch of port
  116. access on your machine. Yeah, this may make you a little nervous, and it
  117. should. But this is actually very harmless beyond maybe losing your
  118. console and having to reboot... Note that you should replace the 0xe4xx
  119. lines with the PCI base you found above.
  120.  
  121. $_ports = "range 0xe400,0xe4ff"
  122.  
  123. Alright. Cross your fingers, do a chicken dance, and type "dos" at the
  124. prompt. if all goes well, you should get some screen flickers / multisync
  125. monitor switches, and see a DOS prompt in 80x25 text mode, maybe with "ATI
  126. GTB BIOS" at the top somewhere. No luck? Sigh.. Try disabling ALL shadow
  127. segments in your BIOS and see if that helps. (You don't need them in 
  128. Linux anyway..)
  129.  
  130. Next step is to get a good DOSEMU hard disk setup. If you haven't done
  131. this already, I recommend setting up an image that has the smallest
  132. (memory-wise) version of DOS you can find. FreeDos will not work! It's too
  133. big! You should also make a copy of the installed "ATI Utility Disk" onto
  134. that DOSEMU image. You can get this utility disk off the ATI FTP site.
  135. Look for "Mach64 Diagnostics and Utilities". Get the newest version! The
  136. one I have is: ftp://ftp.atitech.ca/pub/Install/64utl303.exe
  137.  
  138. Ok, once you've got a DOSEMU setup that has a good amount of free memory
  139. and the M64 utils, we'll start to pull the first bit of black magic. Start
  140. up DOSEMU and then run "M64DIAG". You should get a screen change and then
  141. their goofy test display. Play around a bit, whatever, and once you're
  142. done, make sure to exit the util. Then exit DOSEMU.
  143.  
  144. If you've gotten that far, you're well on your way to getting this work.
  145. If that didn't work, but the DOSEMU startup with graphics BIOS did, then
  146. I don't know what to tell you.. =(
  147.  
  148.  
  149. The Wrong Way(tm)
  150. -----------------
  151. Well, I didn't want to wait to download a new kernel and X server, so I
  152. did things the supa-hack way the first time around. Here's what I did. It
  153. DOES work but it SUCKS! =) And you also can't get TV output.. =(
  154.  
  155. Basically, start Xwindows; switch to a Linux console; start the M64DIAG
  156. program under DOSEMU; select a video mode matching your X11 video mode;
  157. select "Extensions" and then "VT Functions"; use the "Functional Test"
  158. menu to select an input source; select "Demos" and "Video Capture".
  159. Voila. You've now got a big full-screen input window under Linux. Now's
  160. the tricky part... hit CTRL-ALT-F7 to switch back to Xwindows.
  161.  
  162. If smoke doesn't rise from your computer or something similar, I really
  163. want to hear from you. ^_^ For me the image remained, but it chose black
  164. as the key color and then dumped a stream of garbage on the upper part of
  165. my display. One way to get around this is to setup a virtual desktop of,
  166. say, 1280x1024, and then use a 640x480 resolution under X. You can then
  167. scroll down to the bottom part of the screen w/no corruption and watch TV
  168. while using an Xterm (trippy experience =).
  169.  
  170. You can get TV output working in a similar way, but not both at the same
  171. time! (as far as I know..) You just go into DOSEMU and run "INSTALL TVON".
  172. Poof! Problem is, if you try to change video modes without the help of the
  173. ATI BIOS, you're screwed. TV output goes crazy and often the monitor
  174. output doesn't come back at all. Note that you can also get TV output by
  175. attaching a TV to the output when you turn your computer on.
  176.  
  177.  
  178. Recovery
  179. --------
  180. If you are deft at typing without looking at the result, you can switch to
  181. an unused console, log in as root, and kill your current DOSEMU session;
  182. then start a new one. If you are using text mode (like most normal people
  183. in Linux) you can now exit DOSEMU (don't forget to turn off TV output if
  184. going into X) and be fine. This will also work with vesafb (described
  185. below), however. You should just change to the video mode matching your
  186. console in M64DIAG and then switch over to a console. That'll leave an
  187. ugly hardware mouse pointer on your screen, which is going to plague you
  188. all the way through this, but it's better than nothing ;-)
  189.  
  190.  
  191. The Right Way(tm)
  192. -----------------
  193. Well, short of those hosers giving us Linux support anyway.
  194.  
  195. I'm going to start off by saying that this is really involved and unless
  196. you are crazy about seeing that genlock throughput through your Linux box
  197. and being able to subtitle with, e.g., BakaSub, don't bother. If you're a
  198. hacker type and you just can't stand the suspense then go right ahead. I'm
  199. pretty new to this myself but I can also give you some limited assistance
  200. over email if you want to try.
  201.  
  202. Supply list:
  203. - Redhat 5.2 or similarly modern distribution. Make sure it can run Linux
  204.   2.1.12x kernels.
  205. - Relatively modern compiler (can compile new kernels).
  206. - Newest linux 2.1.xxx kernel. I am using 2.1.129 presently, it seems to
  207.   work Ok, though no extensive tests.
  208. - Ok, you've got a little choice on this one. Either obtain the
  209.   X333servonly.tgz package from ftp.xfree86.org (X server sources) or find
  210.   a pre-compiled binary for the FBDev server. I have one, so if you can't
  211.   find it lemme know. I may post it on my web site. If you get the
  212.   sources, you'll need to compile it yourself. You may also need to patch
  213.   fbdev.c -- it got a SEGV on me without some changes.
  214.  
  215. Ignoring the "modern distribution" requirement, this is about 18 megs of
  216. stuff to download. So if you've only got a modem, start it going and go to
  217. bed for the evening or something =)
  218.  
  219. Ok, first thing to do is compile and install a new kernel. This is mostly
  220. covered elsewhere; the pertinent info is that under "code maturity" you
  221. need to enable "prompt for development and/or incomplete drivers" (duhh,
  222. it's a 2.1 kernel =), and under "Console drivers" you need to enable
  223. "video mode selection support", "support for frame buffer devices", and
  224. "VESA VGA graphics console". Compile and install your kernel as per usual.
  225. You may want to take a gander at Documentation/fb/vesafb.txt (in the Linux
  226. sources) so you know what's going on. Pick a nice video mode (I highly
  227. recommend 640x480x16b for subtitling, something bigger for normal usage,
  228. which I don't recommend because it's slow =) and reboot.
  229.  
  230. When the kernel starts up, you'll need to give it the command line
  231. parameter "vga=ask". Hit <ENTER> at the prompt to make it ask you, and
  232. then type the mode number you figured out. E.G., 640x480x16b would be
  233. "311" (what I use). Hit ENTER again and your computer will start to boot
  234. with a beautiful penguin logo at the top (aren't you glad you got into
  235. this?? ^_-; Now you know what the LinuxPPC people have been holding out
  236. on us, because they use this same code for their consoles.)
  237.  
  238. Now get ready to Be Impressed Version 2.0. Run DOSEMU from the console (as
  239. before). If you have a TV output hooked up, it'll be following along with
  240. you hopefully. Run M64DIAG and select the video mode matching what you
  241. told your Vesa frame buffer startup (in my example, 640x480, 16 True
  242. color 565). Exit that menu and go do the "video capture" thing in VT
  243. extensions. Now switch consoles! Bang. You should be watching your video
  244. input in the background of the console. DON'T SWITCH BACK TO DOSEMU! If
  245. you do, you'll lose it all. Instead, do a "killall dos" (fun, wasn't it?
  246. =) and switch consoles a few times to clear everything up. Of course, now
  247. you're stuck with TV input. But hey, if you were following my example, you
  248. are also looking at TV input, going through your Linux box, and out to the
  249. TV! Yes, you are now genlocking your Linux console onto the video stream!
  250. (whoopiee... =)
  251.  
  252. The key to this whole thing, as you have probably figured out, is making
  253. the ATI BIOS take care of video mode switching and TV inputs, without it
  254. realizing it's being hijacked for a much cooler purpose =). And now we
  255. come to what was basically the impossible part before, but which is now
  256. feasable... the X server!
  257.  
  258. The FBDev server was designed specifically for usage with the frame buffer
  259. devices. XFree86 3.3.3 and above have proper support for this server and
  260. the vesafb device in Linux (which we are using). Thus you really need this
  261. version (3.3.3). If you have the precompiled binary from somewhere, skip
  262. down past the part describing configuration and compilation (next few
  263. paragraphs).
  264.  
  265. Remember how I said you should have RedHat 5.2 or something similar? Well,
  266. here's another place it comes in handy. You should have the "Vesafb"
  267. mini-howto for reference. In RedHat 5.2, that's located at
  268. /usr/doc/HOWTO/mini/Vesafb. This file actually has the info you need to
  269. obtain and compile a shiny new XF86_FBDev server. You'll want to get this
  270. thing compiled and then move it into /usr/X11R6/bin (where your
  271. XF86_Mach64 is currently sitting). Although it looks pretty arcane, it is
  272. really very straightforward -- edit the config file the howto mentions
  273. (xc/config/cf/xf86site.def) and change the options you want to change. The
  274. most important is to enable building of the FBDev server. You can also
  275. build a new Mach64 server if you want a real one with internationalization
  276. support.
  277.  
  278. On the kernel I have, the kernel call to do panning around a virtual screen
  279. with a vesafb is apparently not implemented, so the server will segfault on
  280. startup. To fix this (I recommend it since you don't need this feature), edit
  281. the file xc/programs/Xserver/hw/xfree86/fbdev/fbdev.c -- go to the function
  282. "fbdevAdjustFrame" and comment out the "ioctl" line (around line 1324). Save
  283. that and exit. Note that my pre-compiled binary has these changes in it (and
  284. some debug info you can ignore...)
  285.  
  286. Now go to the xc/ directory (root of the X source tree) and type:
  287.  
  288. make World >& world.py &
  289.  
  290. That'll pipe the output into a file you can tail -f if you want, or leave
  291. it in the background. Once that's done, you can "make install" but I
  292. recommend installing the binary itself manually. You'll find it as
  293. xc/programs/Xserver/XF86_FBDev.
  294.  
  295. Ok, everyone should come back to this point (compile or pre-compiled). I'm
  296. assuming that if you got the pre-compiled binary, it went into
  297. /usr/X11R6/bin. Look in /etc/X11 and find the link "X". It should point to
  298. your current X server (XF86_Mach64 if you're set up right). rename that
  299. link to "X.old" and then make a new link like so:
  300.  
  301. cd /etc/X11
  302. mv X X.old
  303. ln -s ../../usr/X11R6/bin/XF86_FBDev X
  304.  
  305. You'll need to do one more thing, which is edit your /etc/XF86Config file
  306. and add a section for the fbdev device. This doesn't seem to be documented
  307. very well (even as well as compiling your own FBDev server), so here's how
  308. you do it. 
  309.  
  310. Add this section next to your existing "Device" section:
  311.  
  312. Section "Device"
  313.    Identifier   "Linux Frame Buffer Device"
  314. EndSection
  315.  
  316. And add this at the bottom:
  317.  
  318. # Framebuffer device
  319. Section "Screen"
  320.     Driver      "fbdev"
  321.     Device      "Linux Frame Buffer Device"
  322.     Monitor     "<MONITOR NAME>"
  323.     DefaultColorDepth 16
  324.     Subsection "Display"
  325.         Depth       8 
  326.         Modes       "default"
  327.     EndSubsection
  328.     Subsection "Display"
  329.         Depth       16
  330.         Modes       "default"
  331.     EndSubsection
  332.     Subsection "Display"
  333.         Depth       32
  334.         Modes       "default"
  335.     EndSubsection
  336. EndSection
  337.  
  338. Replace "<MONITOR NAME>" in the above with whatever your real XF86Config
  339. option for your regular X server says (it's installation dependant!). You
  340. should also use a different number for "16" in the above if you use a 
  341. different color depth.
  342.  
  343. Hold your breath and type 'startx'. You should be presented with an X
  344. display. Note that it is VERY important that *NO MODE CHANGES* happen when
  345. you do this. If they do, something is wrong (maybe your Mach64 server is
  346. still active somehow...)
  347.  
  348. Now what we're gonna do is in principle the same as before, except this
  349. time we'll switch to the console containing the vesafb X server instead of
  350. just another Linux console.
  351.  
  352. Start X windows, and for good measure, get to a shell and type "xsetroot
  353. -solid black". That will chromakey your background. Sorry, you can't
  354. change the key color... =( Use off-black for your fonts. =)
  355.  
  356. Now switch to another console (e.g. CTRL-ALT-F1). Start up DOSEMU as
  357. before, and run M64DIAG, select your video mode, start video capture. Now
  358. switch to the X11 console (CTRL-ALT-F7). If all went well, you should be
  359. looking at genlocked video through your X setup.
  360.  
  361.  
  362. Caveats
  363. -------
  364. Since the first method is one big caveat, I am ignoring it and proceeding
  365. to the second one. =)
  366.  
  367. The first and foremost is the major pain you have to go through to get
  368. this working, even once you get past the initial setup. It's going to
  369. involve a reboot (unless you're crafty) and some config swapping each
  370. time you want to switch between subtitling mode and normal mode.
  371.  
  372. The second caveat is that the vesafb server is VERY slow compared to
  373. the Mach64 server. If you try this you'll find that out *really* fast.
  374. Remember back when your windows used to jerk around while redrawing?
  375. Hellloooo again =). PRO might have a better time at it, my regular
  376. AiW didn't.
  377.  
  378. I mentioned craftiness above... well here's another possibility. The
  379. Mach64 X server doesn't disagree with the vesafb driver in the kernel.
  380. So what you can do (in theory) is start up with the vesafb, but run
  381. your normal Mach64 server (which will clobber the vesafb console, so
  382. you lose your system console... oh whoop.. use xdm =P =). Now you have
  383. a relatively normal setup, and when you want to do subtitling, you
  384. switch to your now defunct console (maybe! I have seen DOSEMU at least
  385. restore the vesafb console successfully!) and kill X. Swap out X
  386. servers (change the symlink in /etc/X11). Start up DOSEMU and get your
  387. subtitling video mode going. Now when you switch consoles from DOSEMU
  388. the vesafb console will be back like normal and you can start up the
  389. vesafb X server. When finished, kill the X server, start up DOSEMU again,
  390. and turn off the TV stuff. Then exit DOSEMU and start up your normal
  391. X config again.
  392.  
  393. Geez, that's all a pain, but unless you want to try and interpret the
  394. several thousand line port traces I got from DOSEMU... ^_^;
  395.  
  396.  
  397. Conclusion
  398. ----------
  399. ATI, you bum-heads, get us some Linux support for this card!! Until then I
  400. guess we'll keep on using stupid workarounds like this one.
  401.  
  402. If you had troubles or have comments, please email me!
  403.  
  404. bard@mail.utexas.edu
  405.  
  406. Also, check out the BakaSub web page (if you haven't done so) at:
  407.  
  408. http://www.dar.net/~dlp/bakasub/
  409.  
  410. --- EOF ---
  411.  
  412.